Modeling languages may be used as meta-languages to describe and execute underlying processes, such as business processes. For example, process modeling languages allow an enterprise to describe tasks of a process, and to automate performance of those tasks in a desired order to achieve a desired result. For instance, the enterprise may implement a number of business software applications, and process modeling may allow coordination of functionalities of these applications, including communications (e.g., messages) between the applications, to achieve a desired result. Further, such process modeling generally relies on language that is common to, and/or interoperable with, many types of software applications and/or development platforms. As a result, process modeling may be used to provide integration of business applications both within and across enterprise organizations.
Thus, such modeling languages allow a flow of activities or tasks to be graphically captured and executed, thereby enabling resources responsible for the activities to be coordinated efficiently and effectively. The flow of work in a process is captured through routing (e.g., control flow) constructs, which allow the tasks in the process to be arranged into the required execution order through sequencing, choices (e.g., decision points allowing alternative branches), parallelism (e.g., tasks running in different branches which execute concurrently), iteration (e.g., looping in branches) and synchronization (e.g., the coming together of different branches).
In the context of such processes, some tasks or activities of the process(es) may require, or may benefit from, execution of multiple instances thereof. Such multiple instances may enable processes to handle more than one instance of an activity at a time, using a single, generic activity description and a single (or single set) of interface(s). For example, during a loan approval process, there may be an activity related to sending a request to a lender for a loan approval. The activity description may relate, for example, to formulation of relevant information associated with the borrower, or to a generation and tracking of request messages sent to the (potential) lender(s), or to receipt and preliminary analysis of any response messages. Thus, rather than formulating different activities for each loan request, the activity may be instantiated multiple times, i.e., once for each request/lender. Then the loan requests may proceed, for example, in parallel, as the various lenders proceed independently to determine whether and how to proceed.
It is possible to execute such multiple instances simply by instantiating the activity in question multiple times, and then allowing the multiple instances to proceed to a point of completion or cancellation, or until some desired goal (e.g., a desired number of responses from lenders) is reached, at which point some aggregation of results may occur. In practice, however, this approach of simply propagating multiple instances of an activity for later aggregation of results thereof may not be suitable or sufficient to achieve a desired result. For example, in practice, each instance may relate to a long-running process, which may itself be subject to unpredictability. Additionally, during execution of the multiple instances, a customer or administrator may wish to have some knowledge about (or exert some control over) one or more of the instances.
Without suitable management of such multiple instances, process resources may be wasted or used inefficiently, and it may be difficult to make intelligent decisions about how to proceed with regard to the overall activity in question. For example, one or more of the instances may turn out to be unsuitable, and it may be sub-optimal to wait until the aggregation of the multiple instances to determine such a lack of suitability. As another example, new information may become available during (or due to) execution of one of the multiple instances, which, if known, may affect execution of some or all of the remaining instances. Generally, then, it may be problematic, but useful, to manage multiple instances of an activity in a controlled, informed manner.